Information drives business. A disaster affecting a data center can cause days or even weeks of unplanned downtime and data loss that could threaten an organization's productivity. For businesses that increasingly depend on data and information for their day-to-day operations, this unplanned downtime can also hurt their reputations and bottom lines. Businesses are becoming increasingly aware of these costs and are taking measures to plan for and recover from disasters.
Two areas of concern when a failure occurs, as well as during the subsequent recovery, are preventing data loss and maintaining data consistency between primary and secondary storage areas. One strategy includes replicating data from local computer systems to backup local computer systems and/or to computer systems at remote sites.
Storage area replication is used to maintain online duplicate copies of data stored in some storage areas, such as disk volumes. The original storage area is called the primary, and the duplicate is called the replica. Replication tries to ensure that the secondary volume contains the same data, location by location, as in the primary volume, while the primary volume is in active use. Typically application software managing the primary data is a separate product from replication software, referred to herein as a replication facility, and the replication facility “captures” data as the data are being written to a storage device by the application software.
To accommodate the variety of business needs, some replication facilities provide remote mirroring of data and replicating data over a wide area or distributed network such as the Internet. Thus, a primary data server may communicate over a network channel with a replica server. However, different types of storage typically require different replication methods. Replication facilities are available for a variety of storage solutions, such as database replication products and file system replication products, although typically a different replication facility is required for each type of storage solution. Other replication facilities are available for replicating all contents of a particular type of storage device but are not configured to replicate data stored on other types of devices.
Replication can occur simultaneously with performing write operations. Under normal circumstances, updated data, also referred to herein as writes, are sent to the secondary node in the order in which they are produced at the primary node. Consequently, the secondary node represents a state of the primary node at a given point in time. If the secondary node takes over due to a disaster, the data storage areas will be consistent.
A replica that faithfully mirrors the primary currently is said to be synchronized or “in sync.” However, problems such as network connectivity failure or host failure may cause the replica data to become unsynchronized, or “out of sync.” An out of sync replica may be synchronized by selectively or completely copying data from the primary; this process is called synchronization or resynchronization.
Previously, the problem of synchronization of backup copies of the data at secondary nodes has been solved by restoring the primary data from a “snapshot” copy of the data made before the primary data became unavailable. First, the primary data are restored or a set of secondary data is selected as a new set of primary data with which to continue further processing. Then the entire set of primary data is copied to each backup copy to ensure consistency between the primary data and backup copies. Only then can normal operations, such as updates and replication, of the primary data resume. When terabytes of primary data are involved, the restoration process is lengthy and the downtime to businesses is very expensive.
Ideally, a log containing addresses of changed storage locations (such as blocks of a storage volume) would be maintained, so that recovery processing can use the log to identify the missing data resulting from write operations that were not performed on each secondary node. The log would be used to replicate only the changed storage locations resulting from those write operations to synchronize each backup copy of the primary data. However, logs are typically written to storage devices, which may require a minimum of 512 bytes (the typical size of a location in a storage area) to be written during each write operation. Write operations perform more efficiently when even larger portions of data are written during each write operation. Typically, contents of a given storage location must be read or written as a whole.
Logging is typically performed by the software managing the primary data. Direct logging in a separate log by a replication facility of each data item stored in each location during replication thus wastes resources by duplicating effort already performed by the data management software. Logging by the replication facility imposes excessive overhead and hinders achievement of the goal of synchronized secondary data. As a result, most replication facilities trade granularity for efficiency by using a regional logging technique, sometimes referred to as dirty region logging, where a single region spans many contiguous storage locations. For example, a typical region size is 64 K bytes. If a change occurs to even one storage location in the region, the entire region is marked for replication to secondary nodes. While replication of only dirty regions is an improvement over replication of all data in the storage area, many blocks that are unchanged are nevertheless copied, wasting storage and network resources.
What is needed is the ability to maintain consistent, up-to-date copies of primary data that enable quick resumption of operations upon stopping and restarting the primary node, or upon temporary failures of the network or the secondary node. The solution should allow write operations and replication to be performed efficiently and without copying all primary data to each secondary node when the primary and secondary data need to be synchronized. Furthermore, the solution should allow only storage locations containing data that have changed to be copied to the secondary node, rather than copying an entire region of data when only a selected few blocks within the region have changed.